We start by presenting some basic concepts to facilitate the understanding of the mechanisms that are presented further on.
Packets
Data networks usually split the data they carry into small units known as packets. Each packet carries a number of headers that are defined by various communication protocols. The great majority of packets carried by commercial networks nowadays are so-called TCP-IP packets. TCP is the Transmission Control Protocol. This makes sure the data arrives reliably (in the correct order and without errors) and is sent to the correct application on the receiver. IP is the Internet Protocol. This ensures the packets are correctly transmitted from the source to the destination. In theory IP is a connectionless protocol—that means each data packet could take a different route to reach the destination. In practice the routing mechanisms on the Internet mean that this seldom happens (unless there is some form of equipment failure).
re-Feedback
One of the functions of the IP header is to carry path information from the sender to the receiver. This path information allows downstream nodes (nodes nearer the receiver) to know the upstream state of the path. Sometimes mechanisms exist to allow the receiver to feedback this information to the sender. The re-Feedback proposal (discussed in the article referred to below as [Briscoe05c]) provides a mechanism whereby the path information that a receiver feeds back to the source can be re-inserted into the forward data path, thus allowing nodes along the path to see the downstream information as well as the upstream information. However it requires one or both end-hosts to actively participate in providing extra signalling in order to achieve this.    [Briscoe05c]: B Briscoe, A Jacquet, C Di Cairano-Gilfedder, A Salvatori, A Soppera & M Koyabe: “Policing Congestion Response in an Internetwork using Re-feedback”, In Proc ACM SIGCOMM'05, Computer Communications Review 35(4) (September 2005).
International patent applications WO 2005/096566 and WO 2005/096567 relate to data networks, and to nodes making up parts of data networks, arranged to derive information relating to the characterisation of paths taken by data travelling between nodes in the networks according to the re-Feedback proposal.
Distributed Bandwidth Sharing and Congestion
Data traversing the Internet follows a path between a series of routers, controlled by various routing protocols. Each router seeks to move the packet closer to its final destination. If too much traffic traverses the same router in the network, the router can become congested and packets start to experience excessive delays whilst using that network path. If sources persist in sending traffic through that router it could become seriously overloaded (congested) and even drop traffic (when its buffers overflow). If sources still persist in sending traffic around this bottleneck it could force more routers to become congested, and if the phenomenon keeps spreading, that can lead to a congestion collapse for the whole Internet—which occurred regularly in the mid-eighties.
The solution to that problem has been to ensure that sources take responsibility for the rate at which they send data over the Internet by implementing congestion control mechanisms. Sources monitor path characterisation metrics to detect when the path their data is following is getting congested, in which case they react by reducing their throughput—while they may slowly increase it when there is no sign of the path getting congested. The typical path characterisation metrics that sources monitor are the average roundtrip time (RTT) for the data path, the variance of the roundtrip time (jitter) and the level of congestion on the path. The congestion is one of the parameters controlling the rate adaptation of a source sending data over a congested path.
The congestion level can be signalled either implicitly (through congested routers dropping packets when their buffers overflow or to protect themselves) or explicitly (through mechanisms such as explicit congestion notification—see next subsection). Currently the most common option is implicit signalling. Historically, routers would drop packets when they got completely saturated (which happens when a traffic burst cannot be accommodated in the buffer of the router)—this policy is called Droptail. Random Early Detection (RED) [RED] is an improvement where routers monitor the average queue length in their buffer and when the average queue is higher than a given threshold, the router starts to drop packets with a probability which increases with the excess length of the queue over the threshold. It is widely used in today's internet because it allows sources to react more promptly to incipient congestion. Sources using TCP are able to detect losses, because a packet loss causes a gap in the sequence; whenever a TCP source detects a loss, it is meant to halve its data transmission rate, which alleviates the congestion on the router at the bottleneck.    [RED]: S Floyd & V Jacobson: “Random Early Detection Gateways for Congestion Avoidance”, IEEE/ACM Transactions on Networking, Vol 1-4 (397-413) August 1993.Explicit Congestion Notification
Explicit Congestion Notification (ECN) [ECN] further improves on RED by using a two-bit ECN field in the IP header to signal congestion. It runs the same algorithm as RED, but instead of dropping a packet, it sets its ECN field to the Congestion Experienced (CE) codepoint. The ECN standard requires the sender to echo any congestion mark signalled in the data; for instance, a TCP receiver sets the Echo Congestion Experienced (ECE) flag in the TCP header, which the TCP source interprets as if the packet has been dropped for the purpose of its rate control. In turn the source then reacts to the congestion by halving its transmission rate and notifies the receiver of this using the Congestion Window Reduced codepoint.    [ECN]: K Ramakrishnan, S Floyd & D Black: “The Addition of Explicit Congestion Notification (ECN)to IP”, RFC 3168, September 2001.
The four values of the two-bit ECN field in the IP header are:                Non ECT, which signifies that the packet belongs to a flow that doesn't support ECN.        ECT(0) and ECT(1), which signify that the packet belongs to a flow that supports ECN but that upstream routers haven't had to mark the packet.        Congestion Experienced (CE) which signals that a packet has experienced incipient congestion.        
It will be understood that allowing a sender to initially assign either of two different codepoints (i.e. “ECT(0)” and “ECT(1)”) to a packet enables the sender to detect if network elements are fraudulently erasing CE codepoints. If a packet which has experienced congestion and therefore has been marked with a “CE” codepoint subsequently has that CE codepoint removed in an attempt to hide the indication that the packet has experienced congestion, this will be detectable by the sender unless the CE codepoint has been changed back to the correct one of the two possible initial codepoints.
Re-ECN
Re-ECN (see [Briscoe08] and [Briscoe09]) is an example of a system that utilises re-feedback to provide upstream and downstream congestion information throughout the network. It is similar to ECN but uses an extra bit in the packet header. This bit enables a number of new codepoints to be used. A simple way to understand the protocol is to think of each packet as having a different colour flag (codepoint). At the start of a flow, a green flag (FNE or feedback not established) is used to indicate that you don't have existing knowledge of the path. Green flags are also used when the sender is unsure about the current state of the path. By default packets are marked with grey flags. If they encounter congestion during their progress through the network they are marked with a red flag. The destination will send back a count of the number of red flags it has seen. For every red flag it is informed of, the sender should send a packet with a black flag (re-echo). These black flags cannot be modified once they are set by the sender. At any intermediate node the upstream congestion is given by the number of red flags seen and the downstream is given by the difference between the number of red and number of black flags.    [Briscoe08]: B Briscoe, A Jacquet, T Moncaster & A Smith: “Re-ECN: Adding Accountability for Causing Congestion to TCP/IP”, IETF Internet Draft draft-briscoe-tsvwg-re-ecn-tcp-05, January 2008.    [Briscoe09]: B Briscoe et al: “Re-ECN: Adding Accountability for Causing Congestion to TCP/IP”, IETF Internet Draft draft-briscoe-tsvwg-re-ecn-tcp-07, March 2009.
It should be noted that while these two documents mention the use of proxies, they fail to indicate how such use could be implemented in an actual system for providing information relating to congestion or any other network characteristics to nodes in a network.
Pre-Congestion Notification
Pre-Congestion Notification (PCN) [PCN] is a mechanism for protecting the quality of service of certain flows within a given region of the network. Flows are only admitted to the network if they won't cause too much congestion. In order to work out if a flow can be admitted, the incipient congestion inside the network is monitored for each path through the network. This allows the ingress node to predict whether there is likely to be congestion for any given flow asking for admission.    [PCN]: P Eardley (editor): “Pre-Congestion Notification Architecture”, IETF internet draft draft-ietf-pcn-architecture-02, November 2007.IP Tunnels
In the context of a data network, tunnelling consists of encapsulating one protocol inside another protocol, and aims to improve the network service, for instance in terms of connectivity (it allows data to get across a network it couldn't get across otherwise), of security (the data is encrypted so it cannot be used if it is intercepted), etc. . . .
A special case of tunnelling is IP-in-IP tunnels where the original header is retained intact and simply encapsulated in another standard IP header at the entrance of the tunnel. The outer IP header source and destination addresses identify the “endpoints” of the tunnel while the inner header preserves the original source and destination addresses for the packet. As the packet traverses the tunnel, the outer header may be modified as the header of any other packet on the same path. When the packet reaches the other end of the tunnel, decapsulation occurs: the outer header is stripped off, the original header fields are updated if necessary, and the packet is forwarded to its original destination.
Other Known Techniques
Proxies are widely used at the application layer for such applications as HTTP, where they can reduce the load on servers and networks by serving popular files themselves. Other popular uses of proxies are to circumvent security controls, for instance to access websites that have been blocked by the user's Internet Service Provider (ISP) or to anonymise the user's network usage.
U.S. Pat. No. 6,101,549 relates to the use of a proxy for a given destination when establishing path reservations in the absence of precise details of the destination, introducing the idea of using proxy headers in order to re-direct data from its original destination to a proxy. This is discussed in relation to the sending of RSVP (resource reservation protocol) messages in order to facilitate the reservation of a path.
Another established use of TCP proxies is in high delay-bandwidth wireless networks such as those operating over satellite. These are designed to improve the performance and reliability of TCP which may be particularly poor when Round-Trip Time (RTT) delays are excessive [Meyer].    [Meyer]: M Meyer, J Sachs & M Holzke: “Performance Evaluation of a TCP Proxy in WCDMA Networks”, IEEE Wireless Communications Vol 10 Issue 5, October 2003.